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(54) Method for enhancing operation of a network management system 



(57) A generic notTications framework (GNF) sys- 
tem (1 03) integrates information from different protocols 
(302) in a management station (100) interfaced with a 
network (118) and permits correlation of the information 
to make more sophisticated management decisions. 
The generic notifications framework system (103) has 
one or more protocol-specific translators (252) in com- 
munication with the network (118). a generic notifica- 
tions framework (254) in communication with the 
translators (252). and one or more consumer compo- 
nents (534) in communication with the framework (254). 
The translators (252) receive event data elements 
(424c) corresponcfing with different management proto- 
cols (302) from the network (118) and translate the 
event data elements (424c) Wo respective canonical 
data structures (424). Each of the canonical data struc- 
tures (424) includes (a) a generic field (424a) that is 
common to generally aB of the canonical data structures 
(424). (b) one or more attribute fields (427) generated 
by the translator (252) based upon an examination of a 
protocol data unit (PDU) (424c) associated with each of 
the event data elements (424c). and (c) a protocol data 
unit (PDU) (424c) that is generally identical to the native 
PDU that arrived with the event data element. Con- 
sumer conrponents (534) register with frie framework 
(254) to receive any canonical data structures (424) 
having particular attribute fields (427). The generic noti- 
fications framework (254) forwards the appropriate 
canonical data structures (424) to appropriate con- 
sumer components (534) based upon the attribute field 
(427) values. A correlator (1406) may be associated 
with the framework (254) to correlate foe canonical data 
structures (424) to derive an intelligent event data ele- 



ment which is essentiafly the result of an assimilation 
and logical evaluation of various event data elements 
(424c). 
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Description 

FIELD OF THE INVENTION 

The present invention generally relates to data 
communication networks, and more particularty. to a 
generic notifications framework (GNF) system and 
method for integrating information from different proto- 
cols in a management station interfaced with a network 
and for permitting correlation of the information to make 
more sophisticated management decisions regarrjng 
the network or station. In addition to network manage- 
ment, these management decisions can ateo be 
directed to higher level system management in the case 
of distributed systems or distributed management appli- 
cations operating above the network. 

BACKGROUND OF THE INVENTION 

A data communications network generafiy includes 
a group of devices, tor instance, computers, repeaters* 
bridges, routers, etc., situated at network nodes and a 
collection of communication channels for interconnect- 
ing the various nodes. Hardware and software associ- 
ated with the network and particularly the devices 
permit the devices to exchange data electronically via 
the communication channels. 

In order to keep track of and manage the various 
devices situated on a network, various management 
protocols have been developed. Examples of these 
management protocols include the Simple Network 
Management Protocol (SNMP). the Common Manage- 
ment Information Protocol (CMIP) standardized by the 
International Organization for Standardization (ISO), 
proprietary protocols frat can be found in proprietary 
network environments, such as SNA™ from IBM Corp. 
and "NETWARE"™ (NW) from Novell Corp.. and remote 
procedure caQ protocols (RPC). such as the distributed 
computing environment protocol (DCE-RPC) that was 
developed by the Open Software Foundation,. The use 
of the foregoing protocols has become extensive in the 
industry, and numerous vendors now manufacture 
many types of network de/ices which can employ these 
protocols. 

Many management software packages ("manage- 
ment platforms") are presently avaBaWe for implement- 
ing •management stations" on a network. Examples of 
comrnerdalry available management software pack- 
ages include "OPENVIEVr™ (or "HP OPENVIEVT™) 
from the Hewlett-Packard Company, which is the 
assignee herein. "NETVIEW"™ from IBM Corp.. "SPEC- 
TRUM"™ from Cabletron Systems, Inc.. "NETLABS 
MANAGER™ from NetLabs. Inc.. and "SUNNET MAN- 
AGER"™ from SunCoonect Inc. The nodes on the net- 
work and their irrter corrections, oftentimes referred to 
as the network "topology.* are best displayed in a graph- 
ical format and most if not an. of the available manage- 
ment software packages provide for this feature. 
Typically, with these packages, a network can be viewed 



from different vantage points, depending on the scope 
of the view that is desired For example, one view f tfce 
network couid be a very wide encompassing view of all 
nodes on the entire network. A second view could be a 
i view of those portions of a network within a local range* 
for example, within a particular site or building. A third 
view of a network, often called a segment could be a 
view of nodes attached to a particular local area net* 
work (LAN) cable. 

10 Hewlett-Packard's very successful •OPENvTEW"™ 
has been the subject of several patents; including for 
^stance. U.S. Patent No. 5.185.860 issued to JXX VAi 
on February 9 % 1993, and U.S. Patent 14a 5.276.789 
issued to Besaw e/a/.,on January 4, 1 994. U.S. Patent 
is Na 5,185.860 descrbes an automatic discovery sys- 
tem for a management system for determining fte net- 
work devices and interconnections of a network, or the 
topology. U.S. Patent No. 5,276.789 describes a graphic 
display system for a management station for graphically 
20 displaying the topology of a network and provides for 
various views (including, internet segment, and node 
views) lhat can be requested by a user. 

Although the presently available management sta- 
tions are merftorious to an extent the art of manage- 
rs merit stations is sta in a state of infancy, and the 
performance of current management stations can stifl 
be enhanced and optimized. A specific area where opti- 
mization is envisioned involves the sharing of informa- 
tion derived from events among appBcations 1haA are 
30 associated with the management stations. Herein, an 
"event" is a notification emitted by any element in the 
managed environment to inoScate a change in state. 
Events are typically asynchronous relative to the man- 
agement station. Moreover. f>ere already exist numer- 
35 ous event forwarding and distribution mechanisms, but 
each is highly tuned to a particular environment or pro- 
tocol domain. This predicament causes several prob- 
lems. 

First many appications require access to nofifica- 

40 bons for more than one of the protocol domains making 
up the managed environment. However, their imple- 
mentation is currently complicated due to the number 
and variety of protocols and interfaces required App*- 
cation access to event data should not be burdened by 

45 a required understandng of the detaied syntax and 
semantics of envuonment-specific protocols, represen- 
tations of, and interfaces to, the event data. 

Second, there is no single, common mechanism for 
gathering notifications from multiple domains. In the 

so context of this document, a "notification - is any mes- 
sage that is emitted asyrK^vonousIy with respect to a 
receiver and in a logjcaffy nonxfirected fashion. In soon 
cases, specific modules have been created to map noS- 
fications from one mechanism to another, but this 

55 results in an "n by m" problem and often distorts the 
kiformation because of the target's environment-spe- 
cific, often nonappficable elements. In some cases, 
information from an original ratification is lost alto- 
gether, because foere is no semanticafy corrparab*e 
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structure in the target. 

Third, applications do not have a common integra- 
tion mechanism for exchanging asynchronous mes- 
sages among the applications. 

Fourth, there is little in the way of shared semantics 5 
between applications to allow the creation of generic 
functions. Specifically, there is no current way to imple- 
ment a common event management console, a com- 
mon filtering mechanism, or common tools that can be 
applied to all variants of event data. 10 

Thus, a heretofore unaddressed need exists in the 
industry for a system and method for enhancing opera- 
tion of a management station on a network by integrat- 
ing and correlating information from different protocols. 

15 



NUMMARY OF THE II 



Briefly described, the present invention is a generic 
notifications framework (GNF) system and method tor 
integrating information from different protocols in a man- 20 
agement station interfaced with a network and for per- 
mitting correlation of the information to make more 
sophisticated management decisions. 

Structurally, the generic notifications framework 
system has one or more protocol-specific translators in 2$ 
communication with the network, a generic notifications 
framework in a^mmuni cation wf&i the translators, and 
one or more consumer components in communication 
with the framework. The translators receive event data 
elements corresponding with different management 30 
protocols from the network and translate the event data 
elements into respective canonical data structures. 
Each of the canonical data structures includes (a) a set 
of generic fields that are common to afl of the canonical 
data structures, (b) one or more attribute fields gener- 35 
ated by the translator based upon an examination of a 
protocol data unit (PDU) associated with each of the 
event data elements, and (c) a protocol data wit (PDU) 
that is generally identical to frie native PDU thai arrived 
with the event data element. In essence, the PDU in the <o 
canonical data structure is an encapsulation of any 
native data so applications friat understand the repre- 
sentation have full access to its contents. 

Consumer components register with me framework 
to receive any canonical data structures having partial- <s 
tar values for attribute fields. Moreover, the generic noti- 
fications framework forwards the appropriate canonical 
data structures to appropriate consumer components 
based upon the values of the attribute fields. 

A correlator, optionally but preferably, may be asso- so 
dated with the framework to correlate the canonical 
data structures to derive an intelligent event data ele- 
ment, which is essentially the result of an assimilation 
and logical evaluation of various event data elements. 
Hence, event data elements are treated and processed s$ 
genetically, and this feature permits more sophisticated 

decisions to be made. 

The present invention provides a generic notifica- 
tions framework method for enhancing operation of a 



management station on a network by integrating infor- 
mation from deferent management protocols, as fol- 
lows: receiving event data elements corresponding with 
(Afferent management protocols from the network; 
translating fre event data elements kilo respective 
canonical data structures, each of the canonical data 
structures inducing at least one attribute field gener- 
ated by examining a protocol data unit associated with 
each of the event data elements; passing the canonical 
data structures to a framework for possible attribution 
to consumer components that are connected to the 
framework; communicating a particular atttoute field 
from a consumer component to the framework to indi- 
cate that the consumer component wishes to receive 
any of the canonical data structures with fre particular 
attribute field; and forwarding a canonical data structure 
with the particular attribute field from the framework to 
the consumer component 

Furthermore, the present invention provides a 
method for errfwong operation of a management sta- 
tion on a network by both integrating and correlating 
information from different management protocols, as 
follows: receiving event data elements from the net- 
work; translating each of the event data elements into a 
canonical data structure, the canonical data structure 
capable of being correlated with ofrier canonical data 
structures corresponcfing to other event data elements 
regardless of protocols associated with tie event data 
elements; and correlating the canonical data structures 
to derive an inteffigent event which is essentiaiy an 
action resulting from a high level inteffigent decision 
derived from assimilation and evaluation of various 
events. 

The present invention has numerous advantages, a 
few of which are delineated hereafter, as examples- 

An advantage is that a protocol-neutral representa- 
tion of each event can be accompBshed. which greatly 
simpfifies the creation of common management mecha- 
nisms, filters, displays, and tools. 

Another advantage is that asynchronous messages 
can be exchanged between applications that operate in 
accordance with different protocols. 

Another advantage is fhaX the interface between 
applications is simpWed. 

Another advantage is that appBcations do not need 
to understand the detafled syntax and semantics 0* 
environment-specific protocols, representations of. and 
interfaces to. the event data in order to corrrnunicate 
between each other. 

Another advantage is that information from different 
protocols can be integrated and correlated so that more 
sophisticated decisions can be made concerning man- 
agement. 

Another advantage is that more sophisticated deci- 
sions can be made for networked computing environ- 
ments having multiple heterogeneous networks and 
network management protocols. 

Other features and advantages of the present 
invention w3 become apparent to one witfi skil in the art 



3 



s 



EP 0 810 755 A2 



upon examination of the following drawings and detailed 
description. It is intended that afl such additional fea- 
tures and advantages be induded herein within the 
scope of the present invention, as is defined in the 
accompanying claims. 

BRIEF DESCRI PTION OF THE DRAWINGS 

The present invention can be better understood 
with reference to the foOowing drawings. Note that Eke 
reference numerals within the drawings designate cor- 
responding parts. 

Rg. 1 is a block diagram illustrating an example of 
implementation of the generic notifications frame- 
work (GNF) system of the present invention in a 
management station, which is the best mode 
known at present for practicing the invention; 
Rg. 2 is a block diagram illustrating the discov- 
ery/layout software and the GNF system of Fig. 1 : 
Fig. 3 is a block diagram illustrating the GNF of Fig. 
1 interfacing various envkonment-specrffc event 
subsystems that operate upon events having differ- 
ent protocols; 

Fig. 4 is a schematic cfiagram illustrating the canon- 
ical data structure for event data that is communi- 
cated through the GNF system of Fig. 1 ; 
Fig. 5 is a block diagram illustrating the roles (/.e. ( 
supplier, consumer, and configurator) that are 
assumed by cornponents that interact with the GNF 
system of Fig. 1 ; 

Rg. 6 is a block diagram illustrating an example of a 
supplier in the form of an event subsystem of Fig. 3; 
and 

Rg. 7 is a block cfiagram illustrating an alarm sub- 
system having correlation functions that is 
employed in connection with the GNF of Fig. 1. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

The generic notifications framework (GNF) system 
of the present invention can be stored on any computer- 
readable mecfium for use by or in connection with a 
cornputer-related system or method. In the context of 
this document a corr^uter-fead^ble medium is an elec- 
tronic, magnetic, optical, or other physical device or 
means that can contain or store a computer program for 
use by or in connection with a computer-related system 
or method. 

The GNF system and method can be implemented 
in virtually any environment that processes asynchro- 
nous events that concern the resources being managed 
in a network, a distributed network, or other communi- 
cation system. In the preferred embodiment the GNF 
system and method are implemented in a management 
station. A management station is any machine that runs 
at least a portion of the management system An exam- 
ple of a management stafion is discussed hereafter for 



purposes of discussion. 

Fig. 1 shows a block diagram of a management sta- 
tion 100 which is implemented with a general purpose 
computer system containing dfecoveryAayout softwar 
s 101 , which utilizes the GNF system 103 and associated 
methodology of the present invention. With reference to 
Fig. 1 . the management station 100 contains any suita- 
ble processor 102. The processor 102 communicates to 
other elements within the management station 100 over 
io a focal interlace 104. for instance, a bus or buses. An 
input device 106. for example, a keyboard or mouse, is 
used to input data from a user of the management sta- 
tion 100. and an output device 108. for example, a ds- 
play or printer, is used to output data to the user. A 
is network interface 112 is used to interface me manage- 
ment station 100 to a network 118 or group of networks 
in order to allow the management station 100 to act as 
a node on the network 118 or group of networks. A 
memory 110 within fre management station 100 stores 
20 the software for driving the processor 102 and generaty 
the station 100. 

As shown, in this embodiment the memory 110 
can include the foOowing hierarchy of software: at the 
highest logical level, one or more management appfica- 
25 tions 105; at the next logical level. riscoveryAayout soft- 
ware 101 situated in a logical sense alongside of the 
GNF system 1 03; and at the lowest logical 1 evel. a con- 
ventional operating system 122 and conventional net- 
work software 124. The one or more management 
30 applications 105 manage, at a high level, an aspect of 
the network 118 or group of networks. Both the discov- 

ery/layout software 101 and the GNF system 103 can 

communicate with the operafing system 122 and net- 
work software 124 to discover the nodes on the network 
35 118. The network software 124 serves as the irrteH- 
gence. including vafidatfoa for the data communication 
protocols. As shown in Fig. 1. t>e network software has 
subsystems 302 that can irrptemertt, as examples. tf*e 
following protocols: SNMP. CMIP. DCE. and proprietary 
40 protocols of the SNA and NW. AH of the foregoing proto- 
cols are well known in the art 

Generally, the cDscoveryAayout software 101 of Fig. 
1 ts configured to cfiscover the network topology, that is, 
an network nodes and node interconnections exisfing 
45 on the network 118. and to construct a map. comprising 
various submaps. any of which can be used for output- 
ting the network topology on tf>e output device 108. 

A high level block diagram of the GNF system 103 
and the cfiscovery/layout software 101 (Fig. 1) is set 
so forth in Rg. 2. With the exception of the GNF system 
103. the architecture of foe discovery/layout software 
101 in Fig. 2 is essentially the same as or similar to the 
architecture of Hewlett-Packard's we8 known and com- 
mercially available management software package 
called -OPENVIEW™. As shown in Fig. 2. at a general 
architecture level, the discovery/layout software 101 
comprises a discovery mechanism 202 lor discovering 
nodes and interconnections of the network 1 18 and a 
layout mechanism 204 for receiving topology data from 
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the. discovery mechanism 202 and tor generating the 
map for driving the output device 108. Moreover, one or 
more management applications 105 may communicate 
display and map information with the layout mechanism 
204. 

The discovery mechanism 202 has a network mon- 
itor 206 connected to the network 1 18 as indicated by 
connection 208. a topology manager 210 connected to 
the network monitor 206 as indicated by arrows 212 and 
through the generic notifications framework (GNF) sys- 
tem 103 that will be described in detail at a later point in 
this document, and a topology database 214 in commu- 
nication with the topology manager 210 as indicated by 
arrow 216. 

The network monitor 206 transmits and receives 
data packets to and from the network 118. The network 
monitor 206 discovers and monitors network topology, 
as indicated by arrow 208. When network topology 
changes on the network, the network monitor 206 gen- 
erates events, or traps (SNMP vernacular), which 
include an object identifier and object change informa- 
tion. The network monitor 206 can also receive events 
from other devices, such as a router, in the network 1 18. 
The network monitor 206 interacts with the network 118 
by way of the network software 124 (Fig. 1). which 
essentially comprises protocol stacks, corresponding to. 
fa exarrple. IP. TCP. UDP. SNMP. ISO. DCS. SNA, and 
NW, and which generally implements these protocols 
and performs validation functions. Furthermore, the net- 
work monitor 206 populates the topology data base 214 
by way of the topology manager 210 and notifies the 
topology manager 210 of events (topology changes). 
Finally, it should be noted that U.S. Patent No 
5.185.860 to Wu. which is incorporated herein by refer- 
ence, describes an example of a node discovery system 
which could be employed to implement the network 
monitor 206 herein. The foregoing monitor focuses 
upon monitoring events pertaining to changes in topol- 
ogy. Other monitors couJd be employed in connection 
with the present invention and directed to rrwnftoring 
other aspects of the environment, in which case ofrer 
types of management information might be passed 
through the monitor and the GNF system 103. 

The topology manager 210 manages the topology 
data base 214. as indicated by bidirectional arrow 216. 
The topology manager 210 prompts toe network mor»- 
tor 206 to update topology data related to particular 
events and receives topology updates, as indicated by 
arrow 212. 

The topology data base 214 stores topology data 
based upon objects, which are used to partition the net- 
work for logical reasons. Objects include, for example 
but not limited to. a network, a segment a computer, a 
router, a repeater, a bridge, etc. Moreover, the topology 
data stored with respect to the objects includes, for 
exarrpte but not fimrted la an interface or device 
address, a device type, a device manufacturer, and 
whether an interface or device supports tfie SNMP. 

The layout mechanism 204 has a topology-to-map 



translator 218 in communication with the topology man- 
ager 210 as indicated by anew 220, a graphical user 
tatertace (GUI) 222 In corrminicafion with fh« topology- 
to-map translator 218 as inotarted by arrow 224. and a 
t map data base 226 in communicafon with the GUI 222 
as indicated by bkfirecfonal arrow 228. The one or 
more applications 105 communteate information with 
the GUI 222, as kxScated by arrow 233. 

The translator 218 converts topology data received 
io from the topology data base 214 and the GNF system 
103 into map data and constructs various submaps in 
the map. The translator 21 8 can forward a request to the 
topology manager 210. as tnoScated by arrow 220. in 
order to obtain topology data regarding particular 
is objects. In adoption to forwaroSng topology data to the 
translator 218 upon request «*e topology manager 210 
advises the translator 218. as indkated by respective 
arrows 220. when topology data has changed based 
upon an even* so that tfte translator 218 can make any 
20 appropriate changes in the submaps. 

Furthermore, the translator 218 can register with 
the GNF system 103 to receive a certain type of topol- 
ogy data or event In turn, when appropriate, the topol- 
ogy manager 210 and tfie GNF system 103 forward the 
25 topology data to fre translator 218. as indicated by 
respective arrows 220. 245. The GNF registration fea- 
ture eliminates the need for the translator 218 to keep 
making requests (poling) for desired data. 

The GUI 222 manages *>e map data base 226. as 
30 indicated by the arrow 228. and manages the input 
de^foe 106 and output device 108. as indicated by the 
respective arrows 230. 231. The GUI 222 receives map 
updates from the translator 218 and submits user-trig- 
gered everts to frie translator 21 8. as indicated by arrow 
35 224. A user-triggered event includes a request 230 from 
a user to explode an object FinaSy. it should be noted 
that U.S. Patent No. 5.276.789 to Besaw et a/., which is 
incorporated herein by reference, descrfoes a graphical 
user interface which could be employed to implement 
40 the GUI 222 herein. 

The GNF system 103 of tfte present invention is in 
communication with the network monitor 206. the topol- 
ogy manager 210. the GUI 222. and the one or more 
applications 105. as incScated by respective arrows 242. 
45 244. 246. and 248 in Fig. 2. In general, the GNF system 
103 enables the sharing of events from cfifferent man- 
agement protocols, such as SNMP. ISO. DOE, SNA, 
and NW. and permits correlafion of the information to 
make more sophisticated management decisions. 
so The GNF system 103 comprises an event translator 
254 and a GNF 254, which are in comrnunication as 
indicated by reference arrow 253. The translator 252 is 
configured to translate event data into a canonical data 
structure (Fig. 4). which is capable or being correlated 
55 with other canonical data structures corresponding to 
other event data, regardless of protocols associated 
with the evert data. Further, the canonical data struc- 
ture enables the GNF system 254 to perform common 
semantic operations, such as fitering, forwarding, trac- 
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ing, and logging. The canonical data structures are for* 
warded by the translator 252 to the GNF 254. which can 
later the canonical data structures and forward the 
structures to any consumers, such as the topology man- 
ager 210. the GUI 222, or an application 105. 

Fig. 3 is a block diagram illustrating the comrnunica- 
tkxi finks that can be established by the GNF system 
103 in the station 100 (Fig. 1). The GNF system 103 
interfaces one or more environment-spedfic event sU>- 
systems 302 conforming to various Afferent protocols 
and. further, interfaces the various subsystems 302 with 
the one or more applications 105. The GNF system 103 
serves as an integration point where event information 
pertaining to events concerning the network 118 is 
shared. The environment-specific evert subsystems 
302 can be directed to any suitable protocol, for 
instance. SNMP. CMIP. and DCE-RPC. or tfx>se proto- 
cols provided by SNA and NW. In the preferred embod- 
iment, tiie subsystems 302 are situated within or 
associated with the network monitor 206 (Fig. 2). More- 
over, one of the management applications 302 can be, 
for example, an alarm subsystem, as is shown in Rg. 3. 

The canonical data structure is shown in Fig. 4 and 
generally denoted by reference nuneral 424. The 
canonical data structure 424 includes generic fields 
424a. extracted attributes 424b, and a native protocol 
data unit (PDU) 424c. In a sense, when transmitted, the 
canonical data structure 424 itself is a form of PDU The 
generic fields 424a are those few attributes which can 
be considered common (or nearly common) to afl envi- 
ronment-specific formats. The extracted attributes are a 
collection of fully-specified attrtoutes, including name, 
type, length, and value, which have been extracted from 
the native formats so they can be interpreted by any 
receiver. The environment-specific PDU 24c is an 
encapsulation of any native data so applications lhat 
understand the representation have fufi access to its 
contents. For some advisory types, a native format may 
not exist or apply in which case the environment-spe- 
cific PDU 424c and. perhaps, the extracted attrfcutes 
424b would be empty. An "advisory" is a notification 
emitted by an element of the management station 100 
(Fig. 1) for the purpose of keeping its normal workings 
properly synchronized. As an example, the structure of 
this canonical data structure 424 can be specified by an 
object management group (OMG) interface definition 
language (IDL) {/.e.. an OMG IDL defined data struc- 
ture), which is a commercially available language for 
describing object interfaces and data structures. 

The generic fields 424a are those that are present 
in all canonical data structure notifications, have a 
widely understood semantic, and have usefii values in 
the vast majority of notfficafion instances. The number, 
position, and type of these fields is fixed, and therefore, 
they may be used by any element in the environment for 
tittering functions. There are relatively few of these 
generic fields 424a.* In a preferred embodiment the 
generic fiefcfs include: a source designation 426a. which 
is a string (printable) containing a name for frie entity 



which originally generated the notification; an environ- 
ment type 426b, which designates the kind of ndttfica- 
tion or the environment in which H originated (examples 
include generic. SNMP. OC€. SNA. NW. CMIP. etc. ; 
s these must be unique values and ftus must be handled 
via a registration service or be inherently unique); an 
origination time 426c which is the time at which th 
notification was Injected into the GNF system 103; an 
extracted attrbutes number 426d. wtwft is the number 
,0 of extracted attributes that foOow; and a PDU length 
426e. which indicates the length ot the native PDU 424c 
as attached to this notification (preferably, a length of 
zero indicates no native PDU present). 

The number of extracted attrfeutes 424b is variable 
is in the canonical data structure 424. The extracted 
attributes 424b comprise a sequence of 4-tupie 
attributes 427a-427d corrtairang a name 428a. a type 
428b. a length 428c and a value 428d Because all ele- 
ments in this sequence are expficd. operations, such as 
20 comparisons for filtering, may be performed on tfiem 
with confidence and wrflxxrt a need to extend toe infra- 
structure for the introduction of new field names. The 
types available include Ihose defined by the OMG IDL. 
The attrtoutes 427a-427d may actuaty be extracted 
25 from an erwonment-specrfic POU 424c when it is 
mapped to the canonical data structue 424 (hence ttie 
name) or simply a variable portion of the notification (in 
the case of advisories). 

The PDU 424c is essentially a string of bits ftat is 
30 uninterpreted by the GNF system 1 03. but is maintained 
by f*e GNF system 103. The PDU 424c usuafy com- 
prises the original, domain specific, event PDU. but may 
be used to pass any other information that wS not be 
interpreted by the QNF system 103. but wiD be for- 
35 warded by it 

The roles that can be played by components which 
interact with the GNF 254 of the GNF system 103 wiU 
now be descrbed with reference to Rg. 5. Essentially, 
there are three roles frat can be played by components 
4o which interact with the GNF system 103: suppBer 532 
(e.g.. the network monitor 206). consumer 534 (eg. . 
the topology manager 210. the GUI 222. an appfication 
105). and configurator 536 (e.g.. the network monitor 
206. the topology manager 210. the GUI 222, an appfi- 
45 cation 105). The suppfier 532 injects management sig- 
nals into the GNF 254 of fre GNF system 103. as 
indicated by reference arrow 538. whereas the con- 
sumer 534 receives management signals from the GNF 
254. as indicated by the reference arrow 539. The GNF 
so 254 receives management signals from the supplier 
based upon registration of the suppler with the GNF 
254. as denoted by reference arrow 542. and the GNF 
254 transfers management signals to the consumer, 
based upon registration of the consumer 534 with the 
55 GNF 254, as denoted by reference arrow 544. In 
essence, the consumer 534 can inform the configurator 
536 what ft is interested in. and the configurator 536 can 
estabfeh a fSter for same. 

The configurator 536 configures the suppfier 532 
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and the GNF 254, as indicated by respective reference 
arrows 535, 537 and receives configuration information 
from the consumer 534, as indicated by reference arrow 
543. Note that in the figures, configuration accesses are 
indicated by narrow elongated bars. The aforemen- 
tioned exchange of configuration information ensures 
consistency among management signals injected, for- 
warded, and received via the GNF 254. It should be 
noted that the foregoing roles are entirety logical in 
nature. A given application or service may in fact play 
any one. two. or all three of these roles. 

At initialization (or possibly later), the configurator 
536 adds one or more titers 541 that the GNF 254 is to 
use in distributing specific management signals. The 
configurator 536 can then set up suppfiers 532 to inject 
management signals of interest into the GNF 254. If 
translation from a native format into the canonical data 
structure 424 (Fig. 4) is being performed by me suppGer 
532. fren the configurator 536 may specify additional 
variations, such as which native attributes are to be 
extracted. At this point the supplier 532 understands its 
mission and can register itseH with the GNF 254 so that 
the GNF 254 can begin generating management sig- 
nals 539. 

The consumer 534 may likewise require configura- 
tion by the configurator 536. if the consumer 534 retains 
the flexibility to dynamically process various manage- 
ment signals 539. In this scenario, the configurator 536 
responds to a fflter request from the consumer 534 by 
forwarding the response to the GNF 254, and the 
response is urtimatefy communicated to the consumer 
534 via the GNF 254. Once the configuration has been 
established, the consumer 534 knows which new sig- 
nals to register with the GNF 254. as delineated by ref- 
erence arrow 544. The consumer registration simpry 
associates the consumer with the results of a ftter. 

Hence, the meeting point (pipe or event channel) 
may be either established by the consumer 534 and 
cornmunicated to the configurator 536 or established by 
the configurator 536 in response to a «er request from 
the consumer 534 and communicated back to the con- 
sumer 534. In either case, this meeting point ts where 
the GNF 254 places events that pass the associated ra- 
ter. 

After the required configuration has taken place, 
the supplier 532 can generate management signals 
538. which are distributed by the GNF system 103 lor 
consumption by the consumer 534. as indicated by the 

reference arrow 539. 

In terms of irr^ementatSon. it is important to 
remember that these roles {i.e.. supplier, consumer, 
and configurator) are logical in nature. Consequently, 
the role of configurator 536 may *m practice be sepa- 
rated among several components or fts presence may 
not even be apparent, if it is imbedded within me sup- 
plier 532 or the consigner 534. Furthermore, a nurrfeer 
of the aforementioned configuration steps are optional 
in that they may not be required by al the irnplemerrta- 
tions or uses of the GNF system 103, especial* a a par- 



ticular supplier 532 and consumer 534 are static in 
terms of the management signals they hand a 

With reference to Fig. 6. stppiers 532 may be 
implemented as event translators 252. which can be 
f dedicated to process events pertaining to the protocols 
SNMP. CM IP. DCE. proprietary protocols of SKA. NW, 
etc. The event translators 252 and their corresponcfing 
event subsystems 302 are interconnected with the net- 
work 1 18 and receive events 602 from the network 118. 
to Events are sent to a specific address and port frat cor- 
respond to each event translator 252 and the event sii>- 
system 302. Each event subsystem 302 forwards 
events 604 to its corresponding event translator 252. 
Moreover, the event translator 252 converts the event 
is data. i e. . the PDU Wo the canonical data structure 424 
(Rg. 4) and transfers tie canonical data structure 424 to 
the GNF 254. as indicated by reference arrow 253 in 

Fig. 6. ^ ^ 

The event translators 252 are configured by the 

20 configurator 536 (Rg. 5). as indicated by arro* 606 in 
Rg. 6, with respect to which environment-specie PDU 
attributes need to be pulled out as extracted attributes 
427a-427d (Fig. 4) in the canonical data structure 424 
(Fig. 4). Addffionaffy. when the event translators 252 are 
25 configured, it is their responsibility to configue their 
associated event subsystem 302 to filer and forward its 
appropriate events to the event translator 252 so that 
the event translator 252 can relay fre selected events to 
the GNF 254. 

30 Optionally, the GNF 254 may be equipped with a 
trace mechanism 6K> and an event log mechanism 612. 
The trace mechanism 610. unifcefr>e event log mecha- 
nism 612. applies to all management signals introduced 
into the GNF 254. The trace mechanism 610. &e the 
35 event log mechanism 612. foUcws the consumer model 
in providing a consigner to receive afl management sig- 
nals and to capture a brief written record of its occur- 
rence. The trace mechanism 610 can serve as a 
debugging and s^port aid and can be designed for 
40 managing management processes themselves. 

The event log mechanism 612 is used to capture a 
record of all event type management signals that have 
been introduced Wo the GNF 254. Particularly, the 
event log mechamsm 612 preserves the data of me 
45 canonical data structure 424 (Fig. 4) for event manage- 
ment signals, described earfier. so that interested appfi- 
cations can access toe generic fields 424a. the 
extracted attributes 424b. and the PDU 424c 

Moreover, the event log mechanism 612 provides a 
so basis for event correlafion and alarm mapping, 
deserved hereinafter, plus it provides a historical record 
of the events that have occurred across all the managed 
environments. The event log mechanism 612 should, of 
course, be configurable to log only the events of inter- 
55 est; not all events forwarded into the GNF 254 need 
necessarily be placed in data storage As such, it rs 
inportarrt to note fiat the event log mechanism 612 has 
rts own consumer **at receives and writes fre events 
into the data base. The only tfflerence between this 
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consumer and consumers S34 * that the log consumer 
is butt Erectly into the GNF 254 for increased perform- 
ance. 

Both the trace mechanism 610 and the event log 
mechanism 612 should be provided with configurable 
interfaces to specify storage policy so avaBabte memory 
does not overflow and entries are deleted according to 
a delberately chosen method. 

The GNF system 103 can be implemented in con- 
nection with an alarm subsystem 702. as is flustrated in 
Rg. 7. In essence, the alarm subsystem 702 uses the 
GNF system 103 in its management c* alarms. In the 
context of this document, an •alarm" Is a recorded inter- 
pretation, with state, of one or more events. The alarm 
subsystem 702 comprises the components used for 
defining, updating, storing, presenting, and giving 
access to alarms. In architecture, the alarm subsystem 
702 corrprises an alarm service 704. one or more cor- 
relators 706 (or correlators), and an alarm console 708. 
The alarm service 704 provides alarm storage services 
710. based upon data received from the correlators 706 
and the console 708. as is indicated by respective refer- 
ence arrows 712, 714. The correlators 706 determine 
when alarms are created. Finally, the console 708 com- 
prises user interlace tools for viewing and manipulating 
alarms. 

The input 716 to the correlators 706 can be pro- 
vided by any management application 105 (Fig. 2) lhat 
listens to management signals or provided by any other 
relevant or suitable input The GNF 254 enables imple- 
mentation of the correlators 706. The correlators 706 
monitor the current state of the managed erwironment 
against alarm conditions or incoming rxrtifications to 
determine when the alarm concStions are true. As these 
corxfrtions become true, the correlators 706 create new 
alarms by interacting with the alarm service 704. 

The alarm service 704 has two primary functions: 
to provide an interface which gives access to alarm 
records in data storage and to generate management 
signals which communicate alarm state changes to 
interested applications 105 (Fig. 2). As the correlators 
706 detect alarm condition state changes, the correla- 
tors 706 invoke the alarm service 704 to create the cor- 
responding alarm or update their state values. Similarly, 
any application 105 can use the alarm service 704 to 
retrieve an alarm or make appropriate changes to the 
alarms. In the preferred errtxxflment me data that is 
available from an alarm record includes: when the alarm 
became true, when the alarm became fake, its state, a 
reference to the definition of its alarm condition, and a 
list of the particular event ictentifications which made the 
alarm condition true. 

As the alarm state changes occur, the alarm serv- 
ice 704 generates management signals 718 for the 
GNF 254 to notify registered applications 105 of the 
changes. These alarm states include, for example but 
not limited to. alarm creation (or validity), alarm 
acknowledgement alarm deletion, alarm irtva&fity (or 
no longer true), alarm escalation, eta 
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The console 708 comprises various tools lor alert- 
ing the user to alarm state changes and enab&ig th$ 
user to view and manipulate alarms. Examples tncfcjde 
an alarm monitor and record browser, an events monitor 
and browser, a trouble-ticketing system, and an alarm 
configurator used tor def ining alarm concStions and reg- 
istering user interest in partictfar alarms. Note that an 
events monitor and browser can be an integral part of 
the alarm console 708. because ft is primarily events 
which constitute alarm conditions. 

An example of alarm to show operation c* the 
alarm subsystem 702 is as to***. Assume tfwt the 
memory 124 (Rg. 1) in the form c* a hard <fek drive is 
rurrting out of memory storage space. Aeon elaior 706 
could be dedicated to monitoring events and determin- 
ing when the dfek memory 124 is approaching fiil 
capacity. When the foregoing correlator 706 determines 
frat the disk memory 124 is approaching Ml capacity. 
Ihe correlator 706 issues a <*sk taw notification 712 to 
the alarm service 704. which in turn issues a <fck low 
notification 718 to the GNF 254. The GNF 254 then 
issues the cfisk tow notfication 720 to a registered 
action server 722, which consumes foe notification and 
executes a script mat hanJes activities to obtain more 
space in the tfsk memory 124. There are numerous 
ofrer examples of alarms, and tte aforementioned 
example should not be limiting. 

In concluding the detailed description, rt should be 
noted that it win be obvious to those sfeUedintheartthat 
many variations and modTications may be made to the 
preferred enixxSmerrts without substantiaBy departing 
from the principles of the present inventory AJI such var- 
iations and modrfications are intended to be included 
herein within the scope of the present invention, as is 
set forth in the following claims. Further, in the claims 
hereafter, the structures, materials, acts, and equiva- 
lents of afl means-pfcis-function or stef>^us-tunction 
elements are intended to include any structures, materi- 
als, or acts for performing the spedfied functions. 
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Claims 

1 . A generic notifications framework system (1 03) for 
enhancing operation of a management station 
(100) on a network (118) by integrating information 
from different management protocols (302). com- 
prising: 

a translator (252) connected to sad network 
(118) to receive event data elements (424c) 
corresponding witfi Afferent management pro- 
tocols (302) from said network (118). said 
translator (252) configtxed to translate said 
event data elements (424c) into respective 
canonic^ data structures (424). each of said 
canonic^ data structures (424) inctoefng at 
least one attribute field (427) generated by said 
translator (252) upon examination erf data 
associated with each of said event data ele- 
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mente (424c); and 

a Qenerfe notifications framework (254) con- 
nected to said translator (252) to receive said 
canonical data structure, said framework (254) 
configured to forward a canonical data struc- 
ture with a particular attribute field (427) to a 
consumer component (534) connected to said 
framework (254), said consumer component 
(534) having previously registered with said 
framework (254) to receive any of said canoni- 
cal data structures (424) with said particular 
attribute field (427). 

2. Trie system (103) of claim 1. further comprising a 
correlator (1406) configured to correlate said 
canonical data structures (424) to derive an inteft- 
gerrt event 

3. The system (103) of claim 1. wherein said canoni- 
cal data structure further includes a generic field 
(424a) that designates a protocol (424c) corre- 
sponding to said event data element 

4. The system (103) of claim 1 . further comprising: 

a plurality of event subsystems (302) con- 
nected to said network (1 18). each one of said 
event subsystems (302) adapted to receive 
event elements (424c) from said network (118) 
having a particular protocol (424c) associated 
said each one; and 

a plurality of translators (252). one c# which is 
said translator (252). each of which are con- 
nected to a respective one of said event sub- 
systems (302). and an of which are connected 
to said framework (254) to provide said canon- 
ical data structures (424) to said framework 
(254). 

5. The system (103) of claim 2. further comprising a 
configurator (536) connected to said framework 
(254) and configured to specify which of said 
canonical data structures (424) are to be forwarded 
to said correlator (1406). 

6. The system (103) of claim 4. further comprising a 
configurator (536) connected to said translators 
(252) and configured to specify which of said event 
data elements (424c) are to be comrnunicated by 
each said translator (252) to said generic notifica- 
tion framework (254). 

7. The system (103) of claim 5. wherein said configu- 
rator (536) is furfrier connected to said translator 
(252) and is further configured to specify which ct 
said event data elements (424c) are to be commu- 
nicated by said translator (252) to said generic noti- 
fication framework (254). 



8. An intelligent integration system (700) for enhanc- 
ing operation of a management station (100) on t 
network (1 18) by correlating and Integrating Infor- 
mation from different protocols (302). comprising: 

5 

a receiver connected to said network (1 18) to 
receive event data elements (424c) corre- 
sponding to different protocols (302) from said 
network (118); 

io a translator (252) connected to said receiver. 

sad translator (252) configured to translate 
each of said event data elements (424c) into a 
canonical data structure, said canonical data 
structure capable of being correlated with other 
15 canonical data structures (424) corresponcfing 

to other event data elements (424c) regardless 
of protocols (302) associated wrfft said event 
data elements (424c); and 
a correlator (706) connected to said translator 
20 (252), said processor configured to correlate 

said canonical data structures (424) to derive 
an intelligent event 

9. A method for enhancing operation of a manage- 
rs ment station (100) on a network (1 18) by integrating 
information from different management protocols 
(302). comprising the steps erf: 

receiving event data elements (424c) corre- 
30 sponding with different management protocols 

(302) from said network (118); 
translating said event data elements (424c) into 
respective canonical data structures (424). 
each of said canonical data structures (424) 
35 including at least one attribute field (427) gen- 

erated by examining a protocol data unit (424c) 
associated with each of said event data ele- 
ments (424c); 

passing said canonical data structures (424) to 
40 a framework (254) for possible cfistrtoution to 

consumer components (534) that are con- 
nected to said framework (254); 
communicating a particular attrixrte field (427) 
from a consumer component (534) to said 
45 framework (254) to indicate that said consumer 

component (534) wishes to recerve any of said 
canonical data structures (424) with said par- 
ticular attrixrte field (427); and 
forwarding a canonical data structure with said 
50 particular attribute field (427) from said frame- 

work (254) to said consumer component (534). 

10. A method for enhancing operation of a manage- 
ment station (100) on a network (i 18) by correlating 
55 and integrating information from different protocols 
(302). comprising the steps of: 

receiving event data elements (424c) from sad 
network (118); 
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translating each of sad event data elements 
(424c) into a canonical data structure, said 
canonical data structure capabl of being cor- 
related with other canonical data structures 
(424) corresponding to other event data ele- $ 
merits (424c) regardless of protocols (302) 
associated with said event data elements 
(424c); and 

correlating said canonical data structures (424) 
to derive an intelligent event Y 
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